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Interoperability  is  what  we  say  we  want 
when  it  is  least  in  evidence 
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Purpose 


•  Workshop 

-  Identify  courses  of  action  for  the  Department  of  the  Navy  to 
address  issues  of  Interoperability  and  Integration  within  the 
DoN  acquisition  process 

•  Briefing 

-  Share  thoughts  and  discuss  factors  that  should  be 
considered  when  identifying  courses  of  action 
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Outline 


•  Vocabulary 

•  Mythology 

•  Challenges 

•  Recommendations 
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Vocabulary 


•  “Interoperability”  or  “Capability”? 

-  We  often  use  the  word  “interoperability”,  when  what  we 
mean  is  “capability” 

-  “Interoperability”  is  a  the  outcome  of  “capability”  provided  by 
an  ensemble 

-  “Capability”  is  easily  measured 

•  “Integration”  or  “Interfacing”? 

-  In  usage,  these  terms  are  often  interchangable,  but  in 
execution  are  very  different 
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Vocabulary  (cont.) 


•  “Integration”  or  “Engineering”? 

-  Integration  is  possible  when  two  or  more  well-characterized 
components  must  be  combined,  through  well-defined  and 
controlled  interfaces,  to  build  some  larger  construct 

•  We  are  in  the  business  of  using  a  disciplined  system 
engineering  process  to  design,  develop,  field,  and 
maintain  warfighting  capability 

-  Integration  and  interfacing  are  necessary  actions 

-  Interoperability  is  an  intended  consequence 
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Mythology 


•  Government  can’t  (shouldn’t?)  lead  engineering 
efforts 

•  Industry  knows  what  the  government  needs  or  wants 

•  Industry  only  does  what  the  Government  says 

•  The  Government  can  issue  independent  performance 
specifications  for  two  or  more  devices  and  expect 
those  devices  to  work  together  to  accomplish  an 
arbritrary  (often  unspecified)  mission 

•  Shortcuts  are  shorter  (cheaper,  better,  ...) 

•  Saying  it’s  so,  makes  it  so 


06/06/2001 


8 


Mythology  (cont.) 


•  Demonstration-based  acquisition  is  a  substitute  for  a 
disciplined,  requirements-based,  system  engineering 
approach 

-  Better 

-  Faster 

-  Cheaper 

-  More  responsive  to  warfighter’s  needs 

•  System  engineering  happens 

•  I’m  okay. .  .you’re  okay. .  .so,  we’re  okay  together, 
right? 
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It’s  closer  to  football  (or  soccer)  than  golf 
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The  old  math 


Functionality  (requirements-driven) 
+  Robust  impiementation  (avaiiabiiity) 
+  Connectivity 
+  Trained  operators 
+  Resources  (doilars  and  peopie) 


Warfighting  capability 
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Capability  shortfalls  --  causes 


•  Physics  of  the  operating  environment 

•  Mission-based  system  requirements  shortfalls 

-  Availability  of  individual  systems  and  equipment 

-  Design  or  implementation  within  individual  units  or  in  the 
interfaces  between  them: 

•  Adequate  specifications  but  poor  impiementation  (program 
“bugs”) 

•  Ambiguous  specifications  that  are  interpreted  differentiy 

•  Specifications  that  are  silent  or  improperly  stated 

•  Shortfalls  in  tactics,  techniques  and  procedures 
(TTP)  and  training 
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Operating  environnnent 
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What  is  the  system? 
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Challenges 


•  Architecture 

-  How  does  it  all  fit  together? 

-  Must  be  able  to  objectively  assess  good  ideas  in  context 

•  Lack  of  understanding  that  interface  requirements  are 

realiy  requirements 

•  Government  and  industry  have  inherentiy  different 

objectives  and  motivating  factors 

-  While  comforting,  the  assumption  that  our  interests  are 
aligned  is  dangerously  naive,  incorrect,  and  doomed  to 
failure 

-  Corporate  America  has  no  responsibility  for  the  common 
defense 

-  Government  has  no  responsibility  for  turning  a  profit 
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Challenges  (cont.) 


•  Familiarity  breeds  contempt 

-  Government  and  industry  have  a  business  relationship,  not  a 
social  relationship 

•  Demographics  of  the  government  workforce,  desire 
to  shrink  the  government  bureaucracy,  the  relentless 
march  of  technology,  and  competition  with  the  private 
sector  for  scarce  human  resources  have  conspired  to 
reduce  the  number  of  people  who  are  competent  to 
lead  the  engineering  and  fielding  of  complex  systems 
to  dangerously  low  levels 

-  Emphasis  on  engineering  leadership 

-  Career  path  clearly  identified? 

-  Life-long  training  and  re-training? 
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Challenges  (cont.) 


•  Our  contracts  appear  to  lack  the  level  of  detail  to 
communicate  the  expectations  of  the  government 

•  Contract  definition  shortfalls  are  compounded  by 
inability  to  verify  compliance 

•  Partnership  relationship  makes  exercise  of 
contractual  remedies  unpleasant 

•  Relationship  of  Award  Fee  and  product  quality  (as 
measured  in  the  field)  is  sometimes  unclear 

•  Crisis  management  isn’t 
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Recommendations 


•  Understand  the  destination 

-  Detailed  model  of  the  desired  end  state 

-  Characterize  the  operating  environment 

-  Understand  the  “partials” 

-  Make  informed  trades  and  decisions 

-  Design  for  success 

•  Pay  attention  to  availability  and  usability 

•  Demand  quality 

-  Don’t  be  amazed  when  it  works  -  be  amazed  when  it  doesn’t 

•  Incentivize  to  meet  requirements 

-  Objectively  reward  performance 
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Recommendations  (com) 


•  Test  wisely 

-  Recognize  that  testing  is  not  a  substitute  for  engineering 

•  Independent  verification  and  validation 

-  Start  with  the  requirement/specification 

-  Build  the  right  system 

-  Build  the  system  right 
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